Multiple Inheritance עזאם מרעי המחלקה למדעי המחשב אוניברסיטת בן-גוריון

Transcription

1 Multiple Inheritance עזאם מרעי המחלקה למדעי המחשב אוניברסיטת בן-גוריון

2 2 Roadmap In this chapter we will investigate some of the logical problems that can arise when a language allows a child class to have multiple parents: Name ambiguity Impact on substitution The Problem of Common Ancestors Implementing multiple inheritance in Java

3 3 Inheritance as Categorization

4 4 Inheritance as Categorization In one sense, the process of inheritance is a form of categorization A TextWindow is a type of Window, so class TextWindow inherits from class Window But in the real world, most objects can be categorized in a variety of ways

5 5 Inheritance as Combination Instead, real world objects are combinations of features from different classification schemes Each category giving some new insight into the whole: Dana is a Female Dana is an Israeli Dana is a Parent Dana is a Professor Note that we have not lost the is-a relationship; it still applies in each case

6 6 Inheritance as Combination Parent Male Professor Israeli

7 7 Is-a, Has-a, and As-a A common analogy in describing multiple inheritance is that of an actor playing different roles Often at the same time Likewise, multiple inheritance is not has-a and not quite the is-a relationship (because the parent class is no longer unique) But a variation of the is-a that could be described as as-a use multiple inheritance if the A can be viewed as-a B sounds right

8 8 CS Example - Complex Numbers Two abstract classifications: Magnitude - things that can be compared Number - things that can perform arithmetic Three specific classes: Integer - comparable and arithmetic Char - comparable but not arithmetic Complex - arithmetic but not comparable

9 9 Possible Solutions 1. Make Number subclass of Magnitude, Complex a subclass of Number but

10 10 Possible Solutions 1. Make Number subclass of Magnitude, Complex a subclass of Number but redefine comparison operators in class Complex to give error message if used (subclassing?????)

11 11 Possible Solutions 1. Make Number subclass of Magnitude, Complex a subclass of Number but redefine comparison operators in class Complex to give error message if used (subclassing for limitation)

12 12 Possible Solutions 1. Make Number subclass of Magnitude, Complex a subclass of Number but redefine comparison operators in class Complex to give error message if used (subclassing for limitation) 2. Don't use inheritance at all - redefine all operators in all classes (flattening the inheritance tree)

13 13 Possible Solutions 1. Make Number subclass of Magnitude, Complex a subclass of Number but redefine comparison operators in class Complex to give error message if used (subclassing for limitation) 2. Don't use inheritance at all - redefine all operators in all classes (flattening the inheritance tree) 3. Use part inheritance, but simulate others - use Number, but have each number implement all relational operators (partial flattening)

14 14 Possible Solutions 1. Make Number subclass of Magnitude, Complex a subclass of Number but redefine comparison operators in class Complex to give error message if used (subclassing for limitation) 2. Don't use inheritance at all - redefine all operators in all classes (flattening the inheritance tree) 3. Use part inheritance, but simulate others - use Number, but have each number implement all relational operators (partial flattening) 4. Make Number and Magnitude independent, and have Integer inherit from both (multiple inheritance)

15 15 Inheritance as a form of Combination This reflects the as-a relationship in a natural way

16 16 Problem with Multiple Inheritance

17 17 Problem with Multiple Inheritance - Name Ambiguity What happens when the same name is used in both parent classes: A CardDeck knows how to draw a Card A GraphicalItem knows how to draw an Image on a screen A GraphicalCardDeck should be able to draw Which? CardDeck draw() GraphicalObject draw() GraphicalCardDeck?

18 18 Problem GraphicalCardDeck gcd; GraphicalCard's constructor called CardDeck's constructor called GraphicalCardDeck's constructor called CardDeck draw() GraphicalObject draw() GraphicalCardDeck?

19 19 Solution A Explicit disambiguation: GraphicalCardDeck gcd; gcd.carddeck::draw(); gcd.graphicalobject::draw(); This solution is less than ideal, since the syntax is different from other function calls, and programmers must remember which method comes from which parent

20 20 Solution B With different type signatures, can use straight overloading: class GCD : public CardDeck, public GraphicalObject { public: virtual Card *draw(){ return CardDeck::draw(); }; virtual void draw(graphicscontext *g){ GraphicalObject::draw(g); }; }; If the type signature are similar, or if overloading is not allowed, then the programmer is faced a more difficult decision.

21 21 Solution C Redefine one or the other operation in the child class: class GraphicalCardDeck : public CardDeck, public GraphicalObject { public: virtual void draw () { return CardDeck::draw(); } } virtual void paint () { GraphicalObject::draw(); } GraphicalCardDeck gcd; gcd->draw(); // selects CardDeck draw gcd->paint(); // selects GraphicalObject draw

22 22 Problem with Redefinition Solution The redefinition solution is not without cost What happens when we run up against the principle of substitution? GraphicalObject *g = new GraphicalCardDeck(); g->draw(); // opps, doing wrong method! This problem can be mitigated, but the solution is complex and not perfect (see next slide)

23 23 A (complicated?) solution 1

24 24 A (complicated?) solution 2 class CardDeckParent : public CardDeck { public: virtual void draw() {carddeckdraw();} virtual void carddeckdraw() {CardDeck::draw()} } class GraphicalObjectParent : public GraphicalObject { public: virtual void draw() {godraw();} virtual void godraw() {GraphicalObject::draw()} } class GraphicalCardDeck: public CardDeckParent, GraphicalObjectParent { public: virtual void carddeckdraw() { } virtual void godraw() { } } // All three variables refer to the same object GraphicalCardDeck *gcd = new GraphicalCardDeck(); CardDeck *cd = gcd; GraphicalObject *go=gcd; cd->draw(); // ok, will execute carddeckdraw go->draw(); // ok, will execute godraw gcd->draw(); //???

25 25 A (complicated?) solution 2 class CardDeckParent : public CardDeck { public: virtual void draw() {carddeckdraw();} virtual void carddeckdraw() {CardDeck::draw()} } class GraphicalObjectParent : public GraphicalObject { public: virtual void draw() {godraw();} virtual void godraw() {GraphicalObject::draw()} } class GraphicalCardDeck: public CardDeckParent, GraphicalObjectParent { public: virtual void carddeckdraw() { } virtual void godraw() { } } // All three variables refer to the same object GraphicalCardDeck *gcd = new GraphicalCardDeck(); CardDeck *cd = gcd; GraphicalObject *go=gcd; cd->draw(); go->draw(); gcd->draw(); // ok, will execute carddeckdraw // ok, will execute godraw // compiler error, ambiguous invocation

26 26 Other Approaches to Name Ambiguity Other languages use different approaches to solving the problem of ambiguous names: Eiffel uses the ability to rename features from the parent class A polymorphic variable accessing through the parents name will access the renamed feature in the child (see next slide)

27 27 Methods redefinition in Eiffel Eiffel allows to directly redefine a method in the sub-class by renaming it in the inherit clause: class GraphicalCardDeck inherit CardDeck rename draw as carddeckdraw end GraphicalObject rename draw as godraw end The solution is roughly equivalent to helper renaming (having a specific parent for each inherited copy) But more efficient and does not require extra classes

28 28 Multiple Inheritance of Interfaces Multiple inheritance of interfaces does not present the same problem of name ambiguity as does multiple inheritance of classes: Either the ambiguous methods in the parent classes have different type signatures, in which case there is no problem, or The ambiguous methods in the parent classes have the same signature Still no problem, since what is inherited is only a specification, not an implementation This is why Java permits multiple inheritance of interfaces, not of classes

29 29 Inheritance from Common Ancestors Does the new object have one or two instances of the ancestor?

30 30 Inheritance from Common Ancestors Does the new object have one or two instances of the ancestor? a a1 a2 b c B C b :A :B :C :D D :A :B :A :C :D

31 31 Sometimes: two instances of the ancestor D * d =new D() A's constructor called B's constructor called A's constructor called C's constructor called D's constructor called :A :B :A :C :D

32 32 Data Field in Common Ancestor Imagine that the common ancestor declares a data member Should the child class have one copy of this data field, or two? Both answers can be justified with examples C++ gets around this by introducing the idea of a virtual parent class: If your parent is virtual there is one copy, and if not there are two Not a perfect solution, and makes the language complicated

33 33 Sometimes: two instances of the ancestor class Link{ public: Link *nextlink; } class CardDeck : public Link { }; class GraphicalObject : public Link{ }; Presumably, the lists of card decks and graphical objects are distinct, and hence each type of list should have its own links

34 34 Sometimes: one instance of the ancestor Stream InStream OutStream InOutStream

35 35 Virtual Inheritance class Stream {...}; class InStream: public virtual Stream {...}; class OutStream: public virtual Stream {...}; class InOutStream: public InStream, public OutStream {...}; The ambiguity occurs in InOutStream, But the solution involves the definitions of InStream and OutStream

36 36 Delegation Simulating Multiple Inheritance with Interfaces Using interfaces and fields can simulate multiple inheritance. For example, we would like class C to extend both A and B Impossible multiple inheritance in Java: class A { public void foo() {...} } class B { public void goo() {...} } class C extends A, B { } // Not allowed in Java!

37 37 Delegation An alternative mechanism for extending classes To make class C extend" B: 1) Define an interface BInf that includes all the public methods of B 2) Make classes B and C implement BInf 3) Add a field of type B to class C 4) Implement BInf in C by delegating all the messages to the new field

38 38 Delegation A Delegation example in Java class A { public void foo() {...} } interface BInf { void goo(); } class B implements BInf { public void goo {...} } class C extneds A implements BInf { private B _b; } public void goo() { _b.goo(); }

39 39 Chapter Summary In this chapter we have explored some of the problems that arise of the concept of multiple inheritance: Name ambiguity Impact on substitution The problem of common ancestors Implementing multiple inheritance in Java